Did you know: to prevent possible data loss before loading the Designer, the following errors must be resolved?

There can be many reasons, one known reason is described here.

In Visual Studio, we have MDriven code that makes up the design-time experience. This is the model and the OCL-Editor and the like.

One of the older things of MDriven are the WindowsForms Handles; ExpressionHandle, ReferenceHandle, and CursorHandle to mention a few.

These handles connect to the DesignTime code for Visual Studio that we find in Eco.Handles.Design.

We run into a problem when Visual Studio compiles your code and finds MDriven assemblies in it - specifically the Eco.Handles.dll. Visual Studio will copy that Eco.Handles.dll from your project and put it in a directory like this:

C:\Users\hans\AppData\Local\Microsoft\VisualStudio\17.0_d364b061Exp\ProjectAssemblies\cobgw1bv.p2l01\Eco.Handles.dll

Now whenever your WindowsForms designer code is de-serialized in design time (executed to actually assign properties) - Visual Studio will first look in ProjectAssemblies and find a copy of Eco.Handles.dll there - it will load this even though we have one loaded from where we installed the MDriven-Extension:

C:\USERS\HANS\APPDATA\LOCAL\MICROSOFT\VISUALSTUDIO\17.0_D364B061EXP\EXTENSIONS\MDRIVEN AB\MDRIVENFRAMEWORK\7.0.0.14859\Eco.Handles.dll

After this has happened, Visual Studio has 2 code bases for the Handles - one that the Plugin uses and one that the WindowsForms de-serialized from.

This gives us strange exceptions as:

Object of type 'Eco.Handles.ExpressionHandle' cannot be converted to type 'Eco.Handles.ElementHandle'.
Method 'Eco.Handles.ColumnCollection.AddRange' not found.

...these exceptions do not make logical sense until one understands that Visual Studio has mixed the code bases from two different places: our MDriven extension installation and your ProjectAssemblies.

To stop Visual Studio from making this mistake, we must ensure that it finds the Eco.Handles.dll from the extension and does not load the Eco.Handles.dll from ProjectFiles.

...it turns out that no matter what probing path we put eco.handles.dll in, we cannot jump in front of the projectassemblies path...

...except when we put the assembly in the GAC - the GAC beats everything, including the ProjectAssemblies...

...Why is GAC not perfect then:

1. The VSIX installation is not allowed to put things into the GAC,
2. GAC will also trump your bin catalog when executing your app (so if you use another version from Nuget - GAC will win).
3. Due to point 2, it becomes important that your MDrivenExtension has the same version as your Nuget packages (EcoCore) - or you may run on other code than you think

How to solve

When using WinForms designer capabilities, you will want the Eco.Handles.dll installed in GAC.

To add Eco.Handles to GAC:

1. Open the AboutForm for MDriven
2. Copy the text from the Gacutil /i option
3. Close the AboutForm
4. Open View/Terminal
5. Paste Gacutil /i option
6. Execute
7. Restart VS.

To remove Eco.Handles from GAC:

1. Open the AboutForm for MDriven
2. Copy the text from the Gacutil /u option
3. Close the AboutForm
4. Open View/Terminal
5. Paste Gacutil /i option
6. Execute
7. Restart VS.